In the downlink direction from 3rd generation radio access networks to terminal devices, the length of each transmitted block of data (called transport block) is not fixed but changes basically all the time. The length of a block of data is thus unknown to the receiver. The term “transport format” is used here as a synonym for the transport block length. The transport format contains also other pieces of information than the block length, but the transport format is detected by detecting the block length. The length of a particular transport block can be signaled in a control channel using a transport format combination indicator (TFCI). If the length is not signaled, then the receiver has to detect the block length blindly (so-called called blind transport format detection (BTFD)) and/or to perform a so-called single transport format detection (STFD) depending on rules specified e.g. in the 3rd Generation Partnership Project (3GPP) specification TS 25.212 section 4.3. For example, in case of WB-AMR, a terminal device (e.g. user equipment (UE)) has to do STFD for the transport format.
Blind transport format detection can be achieved by using a cyclic redundancy check (CRC). CRC is a type of function that takes as input a data stream of any length and produces as output a value of a certain fixed size. The term CRC is often used to denote either the function or the function's output. CRC can be used as a checksum to detect alteration of data during transmission or storage. It is a common method in all communication systems to detect if a data block has errors or not. CRC result is “OK” if the CRC-code check reveals that the data was correct. CRC result is “NOT OK” if CRC-code check reveals that the data was incorrect. The CRC-check may be done after error correction decoding such as Viterbi- or turbo-decoding.
Viterbi-decoding may be applied to a soft decision sample sequence. The correct trellis path of a Viterbi-decoder ends at the zero state at the correct end bit position. The blind transport format detection method using CRC traces back the surviving trellis path ending at the zero state (hypothetical trellis path) at each possible end bit position to recover the data sequence. For each recovered data sequence error-detection is performed by checking the CRC, and if there is no error, the recovered sequence is declared to be correct.
In general, the term “metric” is used hereinafter to designate a measure of similarity between a received code word or signal and one of allowed or candidate code words or signals defined by the underlying coding procedure.
When there is no data at all in the input to the CRC, the CRC will generally say “NOT OK”. However, there will be “false alarms”, i.e. the CRC says “OK”, even though the input was pure noise. The frequency of these false alarms is determined by the strength of the CRC-code. With weak CRC-codes, such as the 8-bit CRC in 3rd Generation Partnership Project (3GPP) WCDMA, there will be false alarms quite often. For example, in the WB-AMR network configuration as specified in 3GPP specification TS 34.108 section 6.10.2.4.1.62, one transport channel with a transport time interval (TTI, time duration of one transport block, e.g. one message) of 20 ms has 8-bit CRC. The purpose of this transport channel is to send signaling information to a terminal device or user equipment (UE) to request the UE to use a certain WB-AMR data rate in the uplink.
However, the transport channel does not always contain data. If there is no data in that channel, the CRC will produce a false alarm once every 256 TTI's which is once every 5 seconds. This may cause a situation where the UE chooses a wrong WB-AMR data rate in the uplink, so that the UE uses an uplink data rate different from that specified by the network.
Hence, CRC may lead to excessive false alarms causing the UE to use a wrong data rate in the uplink. An improved data checking mechanism which leads to less spurious data rate changes would therefore be desirable.